There is actually multiple problems observed:

• the tests are quite slow for what we want to test (want to check correct http calls are done)
• the part generating http responses is difficult to read and non-optimized (used matches(regexp) for constant path)
• we can't control as is exactly which test do what HTTP calls
• all HTTP requests are made on the same server, we don't check which Spring service contact which server

So now:

• passing from a mock-server to mocking rest client
  • using Spring Test solution: MockRestServiceServer
  • inject RestTemplateBuilder in service to easily plugin during tests
  • multiples MockRestServiceServer to have fine grained tests on each services (and also because @RestClientTest support only 1 RestTemplate (good to test only one service) ...)
  • each MockRestServiceServer build with MockServerRestTemplateCustomizer and RestTemplateBuilder
• spitted huge dispatch() block in small atomic expectations+response
• each test specify what calls is expected to be produced and check exactly/only them are made
• also fixed usage of UriComponentsBuilder for query params
• Tests duration pass from 29 tests in ~3s to 38 tests in ~1s.

For the discussion about using a mock-server or not:

There is mainly two way to test HTTP calls:

• starting an HTTP server controlled by the tests (mock-server)
  • It is integration & End-to-End test (slow)
  • libraries like OkHttp MockWebServer or WireMock
  • ...
• mocking or replacing the http class use by services (mock class/functions)
  • It is for integration (or unit?) test (quick)
  • libraries like Mockito can be used
  • Spring offer MockRestServiceServer for mocking RestTemplate directly
  • ...

There is also the point of whether using blocking RestTemplate or non-blocking WebClient.